home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94b.txt / 000032_icon-group-sender _Wed Aug 31 14:01:11 1994.msg < prev    next >
Internet Message Format  |  1995-02-09  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Wed, 31 Aug 1994 08:24:50 MST
  2. To: icon-group-l@cs.arizona.edu
  3. Date: Wed, 31 Aug 1994 14:01:11 GMT
  4. From: goer@quads.uchicago.edu (Richard L. Goerwitz)
  5. Message-Id: <1994Aug31.140111.22639@midway.uchicago.edu>
  6. Organization: University of Chicago
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <33tacj$pen@ios.com>, <1994Aug30.140940.5002@midway.uchicago.edu>, <33vlde$95i@ios.com>
  9. Reply-To: goer@midway.uchicago.edu
  10. Subject: Re: Icon - still alive??
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13. In article <33vlde$95i@ios.com> nmw@ios.com (Nick Williams) writes:
  14. >
  15. >>That's funny.  I feel quite the opposite.  I dread the kitchen sink
  16. >>mentality - turning Icon into a heap of platform-specific extensions
  17. >>geared for things that C and PERL already do much better.
  18. >
  19. >I could deal with loadfunc really (as one of the examples in the IPL
  20. >demonstrates), but some things (setenv() comes to mind...) should be
  21. >standard. If the presence of more system dependent features makes Icon
  22. >programs non-portable, then they can be put in separate libraries along
  23. >with LARGE warnings...
  24.  
  25. Sounds perfectly ghastly - using Icon for something it wasn't really
  26. intended.  The most that I personally would like to see is a solution
  27. to the problem of calling C functions from Icon.  At least this would
  28. let each language do what it does without interference from the other.
  29. Trouble is that the memory management would, at times, conflict (e.g.
  30. if malloc is called).
  31.  
  32. Of course all of this is predicated on resources, and right now the
  33. Icon Project seems absorbed in graphics extensions (which is great).
  34. If improvements are to be made to Icon's C calling interface, this will
  35. need to come from outside, at least for now.
  36.  
  37. >PS: let's not deteriorate into a comp.lang.lisp style language war.
  38.  
  39. :-)
  40.  
  41. -- 
  42.  
  43.    -Richard L. Goerwitz              goer%midway@uchicago.bitnet
  44.    goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
  45.